home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / cpp_libs / varia / dynload.txt < prev    next >
Text File  |  1993-07-24  |  5KB  |  139 lines
  1. DESCRIPTION
  2.   This is a dynamic loader for Sun3 and Sun4.  The interface is very
  3.   simple.  There are three main functions:
  4.  
  5.     setArg0(const char *)  - Call with argv[0] to find main object file
  6.     bool loadFile(const char *fileName) - Load an object file
  7.     long value(const char *sym, int bad=-1) - Find symbol value
  8.  
  9.   This loader reads the object file into memory and does the relocation
  10.   on its own.  This makes it fast and it works even if the main object
  11.   file is dynamically linked (the loaded object file can make calls into
  12.   the shared libraries).  
  13.  
  14.   The advantages of this loader over SunOS 4.1 dlopen() or "ld -A":
  15.     1) Works with normal object files (does not use shared libraries)
  16.     2) Works if the main object file is dynamically linked.
  17.     3) Loaded object can have symbol dependencies into main file or
  18.        previously loaded object files.
  19.     4) It is much faster than the "ld -A" approach.
  20.   The disadvantages:
  21.     1) It will not load every type of file since I have not found ways
  22.        of making all relocation types in Sun object files.
  23.   Other things to note:
  24.     1) It is written in C++.
  25.     2) It is free and unsupported (although I would like to hear of bugs).
  26.  
  27. HISTORY
  28.   This is the second release of my dynamic loader for Sun3/4 C++ OS 4.0.
  29.  
  30. I have tested this on Sun3/280 OS 4.0.3 and Sun4/260 OS 4.0.3.
  31.  
  32. This is as-is software.  You hook it up to your heart-lung machine and
  33. you may be sorry, but I won't be responsible.
  34.  
  35. I can be reached at
  36.  
  37.   Glenn Gribble            glenn@synaptics.com    uunet!synaptx!glenn
  38.   Synaptics, Inc.        (408) 434-0110
  39.   2860 Zanker Road, Suite 105    (408) 434-9819 FAX
  40.   San Jose, CA 95134
  41.  
  42. Some general notes:
  43.  
  44. HOW TO INSTALL THE LOADER
  45.  
  46. This loader will work on a Sun3 and Sun4.  To make the test programs, just
  47. unshar this shar file and type make.
  48.  
  49. After the make, type 'loadtest' to run the test program.  The test program
  50. loads 'sub.o' and prints out a few messages.  Read 'loadtest.cxx' for more
  51. info.
  52.  
  53. PSEUDO MAN PAGES
  54.  
  55. NAME
  56.   loader - A dynamic loader
  57. SYNOPSIS
  58.   #include "loader.h"
  59.  
  60.   void setArg0(const char *arg0);
  61.  
  62.   bool loadFile(const char *dot_oh_file);
  63.  
  64.   long value(const char *sym, int bad=-1);
  65.  
  66. DESCRIPTION
  67.   setArg0() must be called with argv[0] so that the loader can find the
  68.   executable file associated with this program (the loader needs the
  69.   symbols in this file).  setArg0() uses the value of the enviroment
  70.   variable PATH to find what file the program probably came from.
  71.  
  72.   loadFile() loads an object file into memory and calls the constructors
  73.   of that file.  The first time loadFile is called, it initialize the
  74.   dynamic load enviroment by loading the symbols for the running program,
  75.   loading the symbols for the shared libraries, and finding the location
  76.   of the shared libraries in memory.
  77.  
  78.   value() returns the value of a symbol.  For instance to find the location
  79.   of a function "myFunc" in memory, do this (watch out for C++ name mangling):
  80.     long v = value("myFunc",-1);
  81.     if (v == -1)
  82.       printf("myFunc not found\n");
  83.     else
  84.       printf("myFunc is %x\n", v);
  85.   Note that the value of a symbol may change after a new file is loadFile()d,
  86.   because this file may re-define any symbol.
  87.  
  88.  
  89. NAME
  90.   error - formatted error message printing
  91.  
  92. SYNOPSIS
  93.   #include "loader.h"
  94.  
  95.   void error(const char *fmt ...);
  96.   void warn(const char *fmt ...);
  97.   void info(const char *fmt ...);
  98.  
  99. DESCRIPTION
  100.   Print out formatted error/warning/informational messages.  These routines
  101.   can be replaced with more complex routines that print out input file names
  102.   or whatever.
  103.  
  104.  
  105. LOADER THEORY OF OPERATION
  106.   First, the main object file is located by looking for it on the path.
  107.   (This is what setArg0() does.)
  108.  
  109.   The first time loadFile() is called the shared libraries are located
  110.   using information contained in __DYNAMIC and their symbol tables are
  111.   loaded into memory.  The symbol table for the main program is loaded
  112.   into memory after the shared libraries.  The reverse order is necessary
  113.   because a stack of symbols is built up.  During lookup, a symbol is
  114.   first looked up in the loaded object files (most recently loaded first),
  115.   then the main program, and finally the shared libraries.
  116.  
  117.   At this point, the loader is ready to load an object file.
  118.  
  119.   The text and data segments of the object file are loaded into memory
  120.   and space for the bss segment is allocated just after the data segment.
  121.   The symbol table is loaded.  Finally the relocation segments are loaded
  122.   and relocation is performed.  After relocation, the relocation segments
  123.   are unloaded as they are no longer needed.  The symbol table is retained.
  124.  
  125.   Finally, any symbols that look like the symbols for file-level
  126.   constructors (start with "___sti__") are evaluated and the associated
  127.   function called.
  128.  
  129.  
  130. WHAT'S WRONG WITH THIS PICTURE? (or things to do)
  131.   The loader can not cope with certain kinds of relocations.  It should
  132.   be changed to support these other kinds, but so far I have not found
  133.   one in any of my files so I am not sure what the other kinds mean.
  134.  
  135.   Symbol table searching is done linearly at each level in the stack
  136.   of symbol tables.  This could be done in a more intelligent fashion,
  137.   but it has not been a real speed problem.  It might be a problem if
  138.   many symbol lookups were being performed.
  139.